Application development frameworks and programming languages known in the art provide binding mechanisms to facilitate synchronization of properties between data objects. A binding is an attribute of an object where a change in a property of one object is automatically reflected in properties of other objects. Bindings enable the synchronization of object properties to changes within, for example, a user interface or an underlying data store. Application Development frameworks that provide binding technology allow an application developer to synchronize properties, or other data elements, without requiring the application developer to implement extensive amounts of software to manually perform the synchronization. However, the generally known methods of implementing data bindings have shortcomings. The binding methods are not application data-flow aware, in that they do not take into account the desired direction of data-flow within the application. Accordingly, binding methods known in the art may introduce significant system processing overhead due to redundant updates, and may lead to cyclical update loops that can result in application crashes.
FIG. 1 is an illustration of data flow between synchronized data objects when using a two-way binding method to implement a variant of the model-view-controller design pattern, as is known in the art. The model-view-controller (MVC) design pattern assigns objects in an application to one of three roles: model, view, or controller. The pattern defines the roles objects play in the application and the way objects communicate with each other. The illustrated implementation of the MVC pattern binds a property storing a name string.
As illustrated, model.name 102 is the model object for the name property and controller.name 104 is the controller object for the name property. Objects for two separate views, (e.g., view1.name 106 and view2.name 108) are illustrated, which can be used within an application user interface to allow a user to view or manipulate a data object that represents the name property. In the example MVC system of FIG. 1, model.name 102 is bound with view1.name 106 and view2.name 108 via controller.name 104, where view1.name 106 and view2.name 108 are associated with text input fields displayed on a user interface. Data flow in a classical two-way binding implementation as known in the art may follow an update process where, in response to a user providing input a, for example the text field associated with view1.name 106, the name value at view1.name is changed, and view1.name 106 updates model.name 102 via the controller.name 104. After model.name 102 accepts the update, the model updates all bindings via controller.name 104, including both view1.name 106 and view2.name. Accordingly, an update to model.name 102 by view1.name 106 will trigger an update to both view1.name 106 and view2.name 108. The second update to view1.name 106 is an update “cycle” and is redundant. Repeated redundant updates increase data latency, which harms the responsiveness of the data processing system.
Additionally, an ambiguous relationship exists between the data objects and it may not be clear which objects contains the “true,” or most authoritative value within the graph of the binding relationship. When implementing an MVC pattern, it is assumed that the developer has declared the “model” object as truth, but that declaration is conceptual, and is not incorporated within the dataflow.